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1 EP 0 324 

Description 

This invention relates to computer processor archi- 
tecture and operational methods in general, and in par- 
ticular to a method of decoding plural incompatible for- s 
mat instructions. 

The instruction format divergence or compatibility 
problem is fairly well known. Several general strategies 
have evolved for dealing with this compatibility problem. 
One purely software solution involves writing programs 10 
in high level language for compilation specifically for the 
machine which is to run the program. Thus, programs 
must be recompiled into machine language code for 
each new machine required to run them. A library of test- 
ed programs or algorithms can be built up over time and is 
can be migrated to new machines by recompiling them. 
This approach necessarily involves the use of a compiler 
or translator which, of course, must be written for each 
new machine. This is a substantial effort in most instanc- 
es, and in the end does not permit incompatible instruc- 20 
tion formats to reside in the same machine because the 
instructions compiled for a given machine are compatible 
with, and are in the format of, that specific machine 
alone. 

One general architectural approach to resolving the zs 
compatibility problem involves reservation of a bit or 
some bit combination in the instruction format for the ma- 
chine that is to run the program. The extra bit or bit com- 
binations are utilized to flag instructions which are 
non-native format for the machine. Whenever such a flag 30 
combination is encountered, the instruction containing it 
can be decoded using different rules from the native in- 
struction decode rules. This scheme allows non-native 
instructions to be located anywhere in the instruction 
store, but does so at the expense and inconvenience of 35 
lengthening the native instruction word by adding the ad- 
ditional bit or bit combinations. This has the effect of us- 
ing up available instruction decode permutations that 
might otherwise be used for more beneficial purposes 
within the machine. *o 

Another architectural approach, which is related to 
the previously discussed one, is to establish an instruc- 
tion type mode switching control, which may be operated 
by executing a particular instruction. The purpose of the 
"switch" instruction is to permit the programmer to switch 
the host machine's instruction decoding mode from one 
type to another when moving among instructions of var- 
ious types or formats. This requires that the "switch" in- 
struction be included in all subroutine or subprogram en- 
try and exit points which adds unnecessarily to the com- so 
plication of writing programs and increases the amount 
of program storage required. 

Yet another technique for achieving compatibility is 
to use some form of variable decode logic to contain the 
specifications for decoding the machine instructions, ss 
This involves the use of advanced assemblers to pro- 
duce the instruction decode tables that are to be written 
in the variable decode logic. Using this approach, a pro- 
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grammer may tailor an instruction set to suit the applica- 
tion or task which is to be programmed. This approach 
also provides a means for allowing machine language 
programs written in one format for one type of machine 
to be run in another type of machine which is not normally 
compatible with the first machine's instruction format. 
However, the technique does not permit mixing of ma- 
chine language instruction types or formats in a single 
machine. 

Finally, patent application EP01 69565 describes a 
microprocessor adapted for decoding and executing first 
type instructions of a native mode, wherein in an emula- 
tion mode, second type instructions are applied as ad- 
dresses to a conversion memory in which corresponding 
first type instructions are preliminary stored. Each mode 
includes a last instruction to switch over the state of an 
emulation control circuit. 

In view of the foregoing difficulties and shortcomings 
of the known prior art approaches, it is an object of this 
invention to provide an improved data processing archi- 
tectural structure and method of operation in which in- 
structions from two or more incompatible format ma- 
chines may be placed simultaneously in instruction stor- 
age of a single machine and yet be decoded and exe- 
cuted properly. This and other objects not enumerated 
specifically will be apparent in the discussion which fol- 
lows detailing a preferred embodiment of the invention 
and giving several useful examples of its implementa- 
tion. 

In the present invention, instructions from different 
machine types that are written in different formats that 
are normally incompatible, may be placed or intermixed 
in the instruction storage of a single machine and still 
may be decoded and executed properly. The instruc- 
tions, as loaded, are segregated or mapped into areas 
of the instruction store which are uniquely associated 
with containing instructions of a given format or type. Ei- 
ther specific regions of the instruction store may be re- 
served for each type or format of instruction, or instruc- 
tion types identified to the link editor may be loaded and 
a table or map maintained of the locations in storage and 
the format type of instruction that is contained therein. 
The instructions may be then fetched sequentially in nor- 
mal mode for decoding and execution in the machine. 
This is facilitated by utilizing a portion of both the 
fetched-f rom address in instruction storage, from which 
the instruction to be decoded was fetched, and the in- 
struction itself which normally contains one or more fields 
of information that define the type of operation to be per- 
formed, i.e., executed in the machine. The decoding op- 
eration is thus determined in part by where in instruction 
store the instruction resided, as well as by portions of the 
instruction itself, as is the usual case. This technique and 
construction allows normally incompatible format or in- 
struction types from two or more machines to be inter- 
mixed in the instruction store without requiring extra in- 
struction format bits to identify non-native instructions. It 
does not require type or mode switch instructions to be 
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inserted in the instruction stream by the programmer. 
Overall, instructions for a machine of this type consume 
less instruction space than other approaches. 

The invention will be described with reference to a 
preferred embodiment thereof which is further illustrated 
in the drawings in which: 

Figure 1 , consisting of Figures 1 A and 1 B, illustrates 
an exemplary three-phase pipelined processor architec- 
ture and structure utilizing additional components that fa- 
cilitate the decoding operation as defined for the inven- 
tion. 

Figure 2 illustrates the specific additional compo- 
nents and method of operation required in the present 
invention in greater detail. 

Figure 3 illustrates two different instruction formats 
for the same operation as typical examples of two incom- 
patible instruction formats that may be executed to per- 
form the same operation in the processor. 

Figure 4 illustrates a specific example of the opera- 
tion utilizing a first instruction type format for a given in- 
struction in the apparatus of Figures 1 and 2. 

Figure 5 illustrates another example of a different 
format for the same type of execution operation in the 
structure of Figures 1 and 2. 

Figure 6 illustrates the fact that the result of decoding 
either type of instruction in Figures 4 and 5 produces the 
same results in the execution register portion of the ap- 
paratus as depicted. 

A three-phase pipelined data processor architecture 
is illustrated in the descriptions which follow. In this ar- 
chitecture, an instruction is first fetched on one cycle, de- 
coded in the second cycle and executed in the third cycle 
by the processor's arithmetic logic unit. Instructions re- 
side in the instruction store 2 in Figure 1 and are fetched 
into the instruction decoding register 1 for decoding by 
the instruction decoding logic. The decoding logic, which 
may consist of some form of memory or may be imple- 
mented in a more conventional way using standard logic 
elements (i.e., ANDS, ORs, etc.), is used to transform 
fetched instructions to a form appropriate to operate the 
gates and controls of the processor flow logic in such a 
way that the desired instruction execute actions take 
place. The transformed instruction is then placed in the 
Execute Register 4, at the end of decode phase. The in- 
struction address register 3 provides the next instruction 
address to instruction store 2 over the instruction ad- 
dress bus IAB. Instructions are sequentially fetched and 
placed in the instruction decode register 1 and portions 
of the instruction are examined in the address resolving 
logic 6 which contains logic that defines which field or 
fields of the instruction are to be used and (perhaps) 
modified to produce an effective address or direct oper- 
and value. In the example shown in Figure 2, decode 
tables in the instruction decoding memory or logic 5 may 
be loaded externally on line 9. This may provide the load- 
ing of specific instruction decoding rules as will be later 
described. 

The basic ideas presented in this type of structure 



and architecture apply equally well to the non-pipelined 
architectural designs for processing machines as well. 
This will be readily appreciated by those of skill in the art, 
and while the preferred embodiment discussed utilizes 
5 a pipelined architectural design, this is only for conven- 
ience in describing the invention, but has no direct bear- 
ing upon the present invention. 

In Figure 1 , the instruction decode register 1 , abbre- 
viated IDR, is shown. The IDR is the register into which 

10 instructions fetched from the instruction store, called 
I -store 2, are placed to be decoded. Instructions taken 
from, or "fetched'* from, the l-store 2 are placed in the 
IDR where they are held for decoding. The instructions 
are stored in the IDR prior to being decoded in the in- 

is struction decoding logic or memory 5. The instruction ad- 
dress register 3, abbreviated IAR in Figure 1 , is used to 
contain the l-store 2 address for the instruction that is to 
be fetched. The execution register 4, abbreviated EXR, 
contains decoded instructions which are the execution 

20 process codes for the specific machine. Instruction de- 
coding logic elements comprising the instruction decode 
memory or logic as explained earlier, with its contained 
logic, and the address resolving logic 6 are utilized for 
decoding the instructions that reside in the IDR 1. The 

25 address resolving logic extracts specific bits from the in- 
struction in the IDR, based upon the instruction type, and 
then causes an effective address or immediate operand 
value to be calculated by adding (for example) the con- 
tents of some index register (R0 or R4 in Figure 1 B). 

30 in the example illustrated in Figure 1 , l-store 2 is as- 
sumed to be separate from a data store (not shown) and 
is thus a "harvard" architectural design for the machine. 
Loading instructions into l-store 2 may be accomplished 
previously by loading or writing a ROM or RAM chip with 

35 the instructions outside of the host machine. Alternative- 
ly, I -store is RAM, and may be written using special in- 
structions in the host processor repertoire for this pur- 
pose. When this is done, the path is via IDB with IAR 
providing the write address. 

in the example shown, the pipelined processor op- 
erates in such fashion that instructions fetched from the 
l-store 2 are placed in the IDR 1 at the end of a fetch 
cycle. This corresponds to the start of a decoding cycle. 
Then, during the decoding cycle, the instruction con- 

45 tained in the IDR 1 is recoded to a new form appropriate 
for execution by the processor. Simultaneously, the ad- 
dress resolving logic 6 extracts the appropriate instruc- 
tion bits and calculates an effective address or immedi- 
ate value. The end of the decoding cycle, which results 

so in the loading of the decoded bits into EXR 4 and re- 
solved address or immediate value data into the CABR, 
represents the start of the execution cycle. The pipelined 
processor phases thus overlap: while one instruction is 
being fetched, the instruction previously fetched into the 

55 IDR is being decoded and an instruction previously de- 
coded into the EXR 4 is being executed. 

The instruction decode logic in Figure 1 is shown as 
contained in instruction decode memory IDM 5. In the 
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arrangement shown, some or all of the bits from the in- 
struction being decoded in the IDR 1 are used as a por- 
tion of the address utilized to look up a decoded instruc- 
tion code. Which specific bits or fields of the IDR are used 
in the resolved address is determined by the address re- 
solving logic 6 as will be described later in greater detail. 
The content of the instruction decode memory IDM 5 at 
any particular address is, in fact, the execution code for 
a particular decoded instruction. As shown in Figure 2, 
a path 9 for loading the contents of the I DM 5 with decode 
information codes may be included, although this is not 
generally present in most machines. The usual case in 
other machines is for the instruction decode memory to 
be contained in the form of read-only memory and written 
only once. Of course, memory is not the only way for con- 
taining instruction decode specifications since hardwired 
logic configurations are often used, but it is easier to vis- 
ualize the concepts utilizing read/write memory as in this 
illustration. 

The general concept of placing instruction decoding 
tables in memory is extended in the present invention to 
permit placing instructions in various normally incompat- 
ible machine languages or formats into the instruction 
store, and yet allow for proper decoding. The overall ob- 
ject is to permit the programmer to mix or com ingle in 
memory the existing machine language formats or pro- 
grams that may have originally been written for two or 
more different machine types and to permit execution of 
all of the code on a single processor without modifying 
or recompiling the programs. In order to achieve this re- 
sult, a single program which may consist of process in- 
structions or entire sub-routines or code modules from 
dissimilar machines and in dissimilar or incompatible for- 
mats, must be link-edited. The well known function of the 
link editor program, not shown but well known to those 
of skill in the art, is to assign separately identified or oth- 
erwise segregated or mapped locations in the I -store 2 
to the various portions of machine language code being 
used. This may be easily accomplished by reserving ma- 
jor segments, for example the high order address loca- 
tions, for one language or format instruction type and the 
remaining segments in l-store for other languages or for- 
mats. An example of this follows later. 

The technique used in the present invention is rep- 
resented as an extension of the basic concept of utilizing 
an instruction decode memory for containing instruction 
decode specifications or execution codes. This has been 
done for convenience in explaining the architecture and 
method of operation, but is not an essential portion of the 
idea since other forms of instruction decode logic are well 
known. The purpose of having a loadable instruction de- 
code memory 5, as shown in this illustration, is to permit 
tailoring of the instruction set to any specific program- 
ming application. The implication is that each new pro- 
gram application will require its own unique decoding or 
execution code table. If, as is done in the present exam- 
ple, the machine is designed to accommodate and to de- 
code and execute machine level instructions for two or 



more different or incompatible processors, the instruc- 
tion decode memory contents will not generally need to 
be changed for each application. It is only when an ad- 
ditional new instruction set needs to be dealt with that 

s the IDM 5 would have to be loaded with new tables. 

Figure 2 illustrates a block diagram of the major por- 
tions of the logic required to accommodate the changes 
proposed by the preferred embodiment of this invention. 
The logic shown is similar to that in Figure 1 , but omits 

10 the ILR 8 and its loading line 7 for simplicity and includes 
only the elements necessary for implementing the mul- 
tiple instruction type decoding of the present invention. 
In addition, Figure 2 shows an example of the instruction 
store 2 with partitioning illustrated for accommodating 

15 two types of different, incompatible format machine lan- 
guage instructions. As illustrated, the high order ad- 
dresses have been arbitrarily reserved for machine type 
or format 2 instructions. These are identified as having 
the high order address beginning with 111 in binary and 

20 reserve 1 /& of the instruction store total capacity for ma- 
chine type 2 instructions. The remaining addresses are 
arbitrarily reserved for machine type 1 instructions as il- 
lustrated. 

Figure 2 illustrates the addition of a new component, 
25 the Instruction Decode Selection Register, IDSR, 10. 
This element is a register that is operated so that it re- 
tains the instruction address or some portion thereof of 
the instruction currently residing in IDR 1. The IDSR 10 
is used to trap or retain the address of the last instruction 
30 that was fetched from l-store 2. The IDSR 10 retains a 
portion of the address of the last instruction fetched and 
will be clocked with the same signal that causes the IDR 
1 to be loaded. The retained portion may be all of the 
address or less if required. Thus, it will always receive 
35 the address of the instruction that is loaded into the IDR 
1. In Figure 2, IDSR 10 is assumed to contain only the 
high order three bits from the IAR 3 because of the arbi- 
trarily assumed partitioning of l-store 2 in the instant ex- 
ample. Only the three high order bits necessary to define 
40 which of the eight equal arbitrary segments of l-store or 
partitions are being addressed. 

The contents of IDSR 10 and of IDR 1 are taken to- 
gether in Figure 2 to provide a look-up address within the 
IDM 5. Only specific portions of the undecoded instruc- 
ts tion in IDR may be needed according to the format of the 
instruction being fetched. The other portion of the input 
address to the IDM 5 is the output from the IDSR 10 
which identifies the fetched-from address in l-store 2, or 
in the instant example, at least the range in which the 
50 address lies within I -store 2. Decoding of any specific in- 
struction in the IDR 1 thus depends not only on the con- 
tents of the IDR 1 but on the region of the l-store 2 from 
which the instruction was fetched. This portion of the ad- 
dress is provided by the IDSR 10 output. 
55 IDSR 10 also has an output path to the address res- 
olution logic 6. This is necessary to enable the logic to 
access the appropriate bit fields from the IDR 1 when an 
operand or effective address must be formed. In general, 
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there will be no compatibility that can be expected be- 
tween instruction sets of various machines with regard 
to the placement within the instruction, and the length of, 
any operand fields. 

The effect of using the fetched-from address, or por- 
tion of the address, which defines at least a field within 
the I -store regions, as a part of the access specifications 
for decoding the specific instruction that is fetched, is to 
permit instructions in different regions of I -store 2 to be 
decoded utilizing different rules. Thus, if a portion of 
l-store 2 is set aside for "type 2programs, as is shown in 
Figure 2, and if the instruction decode memory 5 is set 
up in the manner described above, all instructions 
fetched from the region of l-store 2 that are identified by 
the three high order address bits 111, will be decoded 
according to type 2 decode rules contained in IDM 5, and 
instructions fetched from the type 1 region in the l-store 
2 will be decoded in the unique manner required for type 
1 instructions. A more specific example is given as fol- 
lows: 

Let us suppose that a "type 1 " format or language 
instruction set requires 24 bit words and that it is desired 
to execute also "type 2" format or language instructions 
that arbitrarily utilize 16 bit words, and that the same ma- 
chine is to be required to handle both types of instruc- 
tions. For the example presently given, it will be assumed 
that each type of original machine for which the instruc- 
tion words were written has an "add registers" instruction 
in a repertoire of its commands. It is, of course, under- 
stood that the function of each command is to cause the 
contents of arbitrary registers such as R2 and R3 to be 
added together and the sum placed in an arbitrary reg- 
ister such as R3. It will be assumed further that the in- 
struction formats like those shown in Figure 3, for exam- 
ple, are utilized. The instruction store will be hypotheti- 
cally partitioned as shown in Figure 2, and type 1 instruc- 
tions would be located somewhere within the lower 7/8 
of the addressing space in the l-store 2; type 2 instruc- 
tions would be located in the upper 1/8 of the address 
spaces in l-store 2. This is accommodated prior to load- 
ing of the instructions into the l-store 2 from an external 
source through the ILR 8 as shown in Figure 1 when the 
instructions have been link edited and examined and 
have been assigned l-store addresses for loading in ac- 
cordance with the type of instruction that they represent. 

When a type 1 add instruction as shown in Figure 3 
is to be exe- cuted, it is first fetched from the l-store 2 
and placed into the IDR 1 . At the same time, the three 
high order address bits of the location in l-store 2 from 
which the instruction was fetched will be loaded into the 
IDSR 10; they will be supplied thereto by the IAR 3. This 
is the fetching cycle, and when it is complete, the regis- 
ters that constitute the IDSR 10 and the IDR 1 will contain 
the specific codes as shown in Figure 4. These have 
come from the segment identified by 01 0 in l-store 2 and 
have the arbitrary contents identified as 726380, the hex- 
idecimal instruction of a type 1 add register's example 
as shown from Figure 3. 



At this point, the contents of the IDR 1 and the IDSR 
10 are taken together to be used as the source of an 
address for looking up the decode execution code rep- 
resented by the instruction in the IDM 5. At the end of 
5 the decoding cycle, the execution register 4 EXR will be 
loaded with the decoded instruction codes that were 
found in the IDM 5 at the location specified by the content 
of the IDR 1 and the IDSR 10 and IDR 1 and IDSR 10 
will be loaded with the next instruction to be decoded and 

10 the address in l-store from which it was fetched, respec- 
tively. The state of the registers at the start of the execu- 
tion cycle is indicated in Figure 6. The contents of the 
IDSR 10 and the IDR 1 are shown as Xs since, for the 
execution cycle, the contents of these registers is imma- 

is terial. However, the contents of the execution register 
EXR 4 shows an exemplary decode operation for an add 
registers operation in which the lower-most EXR register 
cell contains 2, an identification to the ALU of register 2 
which is to be the source of its operand B. The next ad- 

20 jacent cell contains 3 which identifies to the ALU the 
source of its A operand, in this case register 3. The next 
field describes the function to be performed by the ALU, 
in this case 01, meaning an add register and the next 
field describes the carry in selection, in this case, 0 for 

2S an add register's function. 

Continuing the discussion with regard to operations 
of the same sort but written in another format, when a 
type 2 "add registers" instruction is to be executed, then 
that instruction will be fetched in the normal sequential 

30 manner and placed into the IDR 1 just as the type 1 in- 
structions were fetched before. The IAR 3 controls which 
address within the l-store 2 is next accessed and when 
type 2 instructions are reached, they will be decoded and 
executed in sequence as prescribed by whatever pro- 

35 gram has been written. IDSR 10 will receive the three 
high order address bits and will thus contain, in the ex- 
ample shown, the binary content 1 1 1 as illustrated in Fig- 
ure 5. IDR 1 will contain the hexidecimal code as illus- 
trated in Figure 3 for the add register instruction in the 

40 type 2 format which is XX1 A32. The register contents for 
IDSR 10 and IDR 1 are illustrated in Figure 5. It may be 
noted that since the type 2 add registers instruction has 
a word size of only 16 bits in the example assumed, it 
has been placed in the low order 16-bit positions in the 

45 IDR 1 and the high order bits are thus immaterial and are 
shown as Xs. The address resolving logic 6, upon de- 
tecting that the instruction is being fetched from the high 
order range in l-store 2, a fact that is known to address 
resolving logic 6 by virtue of the fact that the content of 

50 the IDSR 1 0 is provided to the address resolving logic 6, 
enables address resolving logic 6 to generate the effec- 
tive address to be placed in the CABR. 

During the decoding cycle that follows the fetching 
cycle, IDR 1 and IDSR 10 contents, or portions thereof, 

55 are used together as the address for looking up the de- 
code of the specific instruction of the type 2 add registers 
in the IDM 5 logic or memory. It will be noted that the two 
high order bytes of the IDR 1 will have no part in decoding 
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of the instruction since they do not exist in type 2 instruc- 
tions. Thus, the address used for IDM 5 will be entirely 
different from that used for looking up the decode of the 
type 1 instruction example just given. However, the in- 
struction decode memory IDM 5 will be configured to 
contain the same pattern of decoded bits. That is, the 
execution code to be placed in EXR will be identical since 
exactly the same function is specified by both the type 1 
add register's instruction and the type 2 add register's 
instruction. Therefore, the state of the execution register 
4 after the type 2 add register's instruction has been suc- 
cessfully decoded is represented in Figure 6 as being 
just the same as it was for the type 1 instruction. 

As is evident from the foregoing description of the 
structure and operation of the present invention, the de- 
code memory table or hardwired logic as used in the 
present invention will require somewhat greater content 
to support decodes of multiple instruction types or for- 
mats than those that are required to support a single in- 
struction format or type. Also, certain conditions must be 
met or must pre-exist when multiple types of machine 
level instructions are to co-exist within a single machine 
for decoding and execution. The essential conditions are 
that the machine level instructions for one machine type 
to be executed directly in another require the executing 
machine to have at least equivalent data flow path widths 
and arithmetic logic resources. For example, if a partic- 
ular instruction directs multiplication to take place, the 
data flow of the hosting machine must have a multiplier, 
and the relationship of the multiplier to other necessary 
arithmetic elements must be similar to those provided in 
the machine for which the original program was written. 
Secondly, all instructions that reside in the I -store 2 of 
the machine must be able to fit within the word size of 
that I store. Thus, instructions from a 24-bit wide instruc- 
tion word machine to be executed in a non-native host 
machine will require that the host machine have at least 
a 24-bit instruction word size of its own to accommodate 
those from the first machine. Finally, the address resolv- 
ing facilities, i.e. , the number of index registers, the index 
adder sizes, etc., for the hosting machine must be ade- 
quate to accommodate the effective address and oper- 
and formation for the non-native machine instructions as 
will be evident to those of skill in the field. 

Having described the invention with reference to a 
preferred embodiment thereof, and having clearly ex- 
plained that both the method and apparatus of the inven- 
tion may be practiced in other than pipelined machine 
architectures, it will be apparent to those of skill in the art 
that numerous departures from the specific embodiment 
are contemplated and will adequately perform the meth- 
ods described wherefore what is set forth in the claims 
which follow are intended to be by way of example only 
and not by way of limitation. 



10 
Claims 

1 . A method of decoding for execution normally incom- 
patible plural format instructions (Type 1 , Type 2) 

5 into compatible single format execution codes in a 
processor, the method comprising the step of : 

- fetching sequentially for decoding and execu- 
tion said instructions from a first addressable 
10 storage means (2), 

the method being characterized by the step of: 
decoding sequentially said fetched instructions 
for execution in said processor by accessing ex- 
ecution codes stored in a second addressable 
15 storage means (5) by utilizing at least a portion 

of the address (IAB) in said first addressable 
storage (2) from which each said instruction was 
fetched together with at least a portion of said 
fetched instruction (IB) itself as the address for 
20 said second addressable storage means (5). 

2. The method as described in Claim 1 , further com- 
prising the step of segregating by format said 
instructions into separately identifiable groups of 

25 locations (upper 1/8th, lower 7/8th) in said first 
addressable storage means (2). 

3. The method as described in Claim 1, further com- 
prising the step of retaining sequentially the 

30 addresses in said first addressable storage means 
(2) from which said instructions are fetched. 

4. The method as described in any of Claims 1 to 3, 
further comprising the step of arranging for access 
the execution codes for each said instruction in said 
second addressable storage means (5), said 
arranging being done at locations therein that are 
determined by at least a portion of each said instruc- 
tion together with at least a portion of the address in 
said first addressable storage means wherein said 
instruction resides. 

5. Data processing system comprising an apparatus 
for decoding for execution normally incompatible 
plural format instructions (Type 1 , Type 2) into com- 
patible single format execution codes, said appara- 
tus comprising a first addressable storage means 
(2) acting as an instruction store, said instruction 
store containing instructions in two or more incom- 
patible formats for execution in said data processing 
system, 

said data processing system being character- 
ized in that said apparatus further comprises a 
second addressable storage means (5) acting 
as an execution code store, the contents of said 
execution code store being arranged to be 
addressed for each said instruction in said 
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instruction store (2) by an address utilizing at 
least a portion of said instruction (IB) together 
with at least a portion of the address (IAB) in 
said instruction store (2) at which said instruc- 
tion resides. 5 

6. The data processing system of Claim 5 further com- 
prising means for retrieving sequentially the 
addresses in said first addressable storage means 
(2) from which said instructions are fetched. 10 



Patentanspruche 

1. Verfahren zum Decodieren verschiedenformatiger is 
normalerweise inkompatibler Befehle (Typ1 , Typ2) 

in kompatible Befehle eines einzelnen Formates im 
Maschinencode in einem Prozessor, wobei das Ver- 
fahren den folgenden Schritt umfaGt: 

20 

sequentielles Abrufen der Befehle aus einem 
ersten adressierbaren Speichermittel (2) zum 
Decodieren und Ausfuhren, 

wobei das Verfahren durch die folgenden Schritte 25 
gekennzeichnet ist: 

sequentielles Decodieren der abgerufenen Be- 
fehle zur Ausf uhrung in dem Prozessor, indem 
auf Maschinencode zugegriffen wird, der in ei- 30 
nem zweiten adressierbaren Speichermittel (5) 
gespeichert ist, und zwar unter Verwendung 
von mindestens einem Teil der Adresse (IAB) 
innerhalb des ersten adressierbaren Speicher- 
mittels (2), aus welchem der Befehl abgerufen 35 
wurde, zusammen mit mindestens einem Teil 
des abgerufenen Befehls (IB) selbst als Adres- 
se fur das zweite adressierbare Speichermittel 
(5). 

40 

2. Verfahren gemaG Anspruch 1, desweiteren den 
Schritt des formatgesteuerten Aufspaltens der 
Befehle in separat identifizierbare Gruppen von 
Speicherplatzen (oberes 1/8el, unteres 7/8el) inner- 
halb des ersten adressierbaren Speichermittels (2) 4$ 
umfassend. 

3. Verfahren gemaB Anspruch 1, desweiteren den 
Schritt des sequentiellen Beibehaltens der Adres- 
sen innerhalb des ersten adressierbaren Speicher- so 
mittels (2), aus dem die Befehle abgerufen werden, 
umfassend. 

4. Verfahren nach einem der Anspruche 1 bis 3, des- 
weiteren den Schritt des fur den Zugriff Anordnens ss 
des Maschinencodes jedes Befehls innerhalb des 
zweiten adressierbaren Speichermittels (5) umfas- 
send, wobei das Anordnen auf Platzen erfolgt, die 



durch mindestens einen Teil jedes Befehls zusam- 
men mit mindestens einem Teil der Adresse in dem 
ersten adressierbaren Speichermittel, worin der 
Befehl steht, bestimmt werden. 

5. Datenverarbeitungssystem, das eine Vorrichtung 
zum Decodieren verschiedenformatiger normaler- 
weise inkompatibler Befehle (Typ1 , Typ2) in kompa- 
tible Befehle eines einzelnen Maschinencodeforma- 
tes umfaGt, wobei die Vorrichtung ein erstes adres- 
sierbares Speichermittel (2) umfaGt, das als 
Befehlsspeicher dient. wobei der Befehlsspeicher 
Befehle in zwei Oder mehreren inkompatiblen For- 
maten zur Ausfuhrung in dem Datenverarbeitungs- 
system enthalt, 

wobei das Datenverarbeitungssystem dadurch 
gekennzeichnet ist, daG die Vorrichtung des- 
weiteren ein zweites adressierbares Speicher- 
mittel (5) umfaGt, das als Maschinencodespei- 
cher dient, wobei der Inhalt des Maschinenco- 
despeichers so angeordnet wird, daG er fur 
jeden Befehl im Befehlsspeicher (2) durch eine 
Adresse adressiert wird, die mindestens einen 
Teil des Befehls (IB) zusammen mit mindestens 
einem Teil der Adresse (IAB) innerhalb des 
Befehlsspeichers (2), in welchem der Befehl 
steht, benutzt. 

6. Datenverarbeitungssystem gemaG Anspruch 5, 
desweiteren Mittel zum sequentiellen Auslesen der 
Adressen innerhalb des ersten adressierbaren 
Speichermittels (2), aus dem die Befehle abgerufen 
werden, umfassend. 



Revendications 

1. Methode de decodage pour I'execution d'instruc- 
tions de plusieurs formats norma lement incompati- 
bles (Type 1, Type 2) en des codes d'execution de 
format unique compatible dans un processeur, com- 
prenant I'etape de: 

extraire en sequentiel, pour le decodage et 
('execution desdites instructions, dans un pre- 
mier moyen d'emmagasinage adressable (2), 
la methode etant caracteris6e par I'etape de: 
decoder en sequentiel lesdites instructions 
extraites pour execution dans ledit processeur 
en ayant acces a des codes d'execution emma- 
gasines dans un deuxieme moyen d'emmaga- 
sinage adressable (3) en utilisant au moins une 
portion de I'adresse (IAB) dans ledit premier 
moyen d'emmagasinage adressable (2) d'ou a 
ete extraite chaque dite instruction ainsi qu'au 
moins une portion de ladite instruction extraite 
(IB) meme comme etant I'adresse dudit 
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deuxieme moyen d'emmagasinage adressable 
(5). 

2. M6thode selon la revendication 1, comprenant en 
outre retape de s6gr6guer par format lesdites ins- s 
tructions en groupes s6par6ment identifiables 
d'emplacements (le 1/Sieme superieur, Ies7/8iemes 
inf6rieurs) dans ledit premier moyen d'emmagasi- 
nage adressable (2). 

10 

3. M6thode sefon la revendication 1, comprenant en 
outre I'etape de maintenir en sSquentiel les adres- 
ses dans ledit premier moyen d'emmagasinage 
adressable (2) d'ou sont extraites lesdites instruc- 
tions. 15 



4. Methode selon Tune quelconque des revendications 
1 a 3, comprenant en outre I'etape d'arrangement, 
en vue d'un acces, des codes d'execution de chaque 
dite instruction dans ledit deuxieme moyen d'emma- 20 
gasinage adressable (5), ledit arrangement s*y fai- 
sant en des emplacements qui sont determines par 

au moins une portion de chaque dite instruction ainsi 
que par au moins une portion de I'adresse dans ledit 
premier moyen d'emmagasinage adressable dans 25 
lequel resident lesdites instructions. 

5. Systeme de traitement de donnees comprenant un 
appareil pour decoder pour execution des instruc- 
tions de plusieurs formats normalement incompati- 30 
bles (Type 1, Type 2) en des codes d'execution de 
format unique compatible, ledit appareil comprenant 

un premier moyen d'emmagasinage adressable (2) 
jouant le rdle de memoire ^instructions, ladite 
memoire d' instructions contenant des instructions 35 
dans deux ou plusieurs formats incompatibles pour 
execution dans ledit systeme de traitement de don- 
nees, 

ledit systeme de traitement de donn6es 6tant 40 
caracterise en ce que ledit appareil comprend 
en outre un deuxieme moyen d'emmagasinage 
adressable (5) jouant le role de memoire de 
codes d'execution, le contenu de ladite 
m6moire de codes d'execution etant arrange de 
maniere a dtre adresse pour chaque dite ins- 
truction dans ladite memoire ^instructions (2) 
par une adresse utilisant au moins une portion 
de ladite instruction (IB) ainsi qu'au moins une 
portion de I'adresse (IAB) dans ladite memoire so 
destructions (2) ou reside ladite instruction. 

6. Systeme de traitement de donnees selon la reven- 
dication 5, comprenant en outre un moyen pour 
recuperer en sequentiel les adresses dans ledit pre- 55 
mier moyen d'emmagasinage adressable (2) d'ou 
sont extraites lesdites instructions. 
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